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CHAPTER  1 


INTRODUCTION 


The  Ada  inplementation  described  above  was  tested  according  to  the  Ada 
Validation  Procedures  [Pro95]  against  the  Ada  Standard  [Ada83]  using  the 
current  Ada  Compiler  Validation  Capability  (ACVC).  This  Validation  Summary 
Report  (VSR)  gives  an  account  of  the  testing  of  this  Ada  inplementation.  For 
any  technical  terms  used  in  this  report,  the  reader  is  referred  to  [Pro95]. 
A  detailed  description  of  the  ACVC  may  be  found  in  the  current  ACVC  User's 
Guide  [UG89]. 


1.1  USE  OF  THIS  VALIDATION  SUMMARY  REPORT 

Consistent  with  the  national  laws  of  the  originating  country,  the  Ada 
Certification  Body  may  make  full  and  free  public  disclosure  of  this  report. 
In  the  United  States,  this  is  provided  in  accordance  with  the  "Freedom  of 
Information  Act"  (5  U.S.C.  #552).  The  results  of  this  validation  apply  only 
to  the  conputers,  operating  systems,  and  coitpiler  versions  identified  in  this 
report. 

The  organizations  represented  on  the  signature  page  of  this  report  do  not 
represent  or  warrant  that  all  statements  set  forth  in  this  report  are 
accurate  and  complete,  or  that  the  siibject  inplementation  has  no 
nonconforinities  to  the  Ada  Standard  other  than  those  presented.  Copies  of 
this  report  are  available  to  the  pi±»lic  from  the  AVF  vdiich  performed  this 
validation  or  from; 

National  Technical  Information  Service 
5285  Port  Royal  Road 
Springfield  VA  22161 

Questions  regarding  this  report  or  the  validation  test  results  should  be 
directed  to  the  AVF  vAiich  performed  this  validation  or  to: 

Ada  Validation  Organization 

Conputer  and  Software  Engineering  Division 

Institute  for  Defense  Analyses 

1801  North  Beauregard  Street 

Alexandria  VA  22311-1772 


1-1 


INTRODUCTION 


1.2  REFERENCES 

[Ada83]  Reference  Manual  for  the  Ada  Programming  Language, 

ANSI/MIL-STD-1815A,  February  1983  and  ISO  6652-1987. 

[Pro95]  Ada  Compiler  Validation  Procedures,  Version  4.0,  Ada  Joint 
Program  office,  January  1995. 

IUG89]  Ada  Conpiler  Validation  Capability  User^s  Guide,  21  June  1989. 


1.3  ACVC  TEST  CLASSES 

Coitpliance  of  Ada  inplementations  is  tested  by  means  of  the  ACVC.  The  ACVC 
contains  a  collection  of  test  programs  structured  into  six  test  classes:  A, 
B,  C,  D,  E,  and  L.  The  first  letter  of  a  test  name  identifies  the  class  to 
which  it  belongs.  Class  A,  C,  D,  and  E  tests  are  executable.  Class  B  and 
class  L  tests  are  expected  to  produce  errors  at  compile  time  and  link  time, 
respectively. 

The  executable  tests  are  written  in  a  self-checking  manner  and  produce  a 
PASSED,  FAILED,  or  NOT  APPLICABLE  message  indicating  the  result  vdien  they  are 
executed.  Three  Ada  library  units,  the  packages  REPORT  emd  SPPRT13,  and  the 
procedure  CHECK_FILE  are  used  for  this  purpose.  The  package  REPORT  also 
provides  a  set  of  identity  functions  used  to  defeat  some  compiler 
optimizations  allowed  by  the  Ada  Standard  that  would  circumvent  a  test 
objective.  The  package  SPPRT13  is  used  by  many  tests  for  Chapter  13  of  the 
Ada  Standard.  The  procedure  CHECK_FILE  is  used  to  check  the  contents  of  text 
files  written  by  some  of  the  Class  C  tests  for  Chapter  14  of  the  Ada 
Standard.  The  operation  of  REPORT  and  CHECK_FILE  is  checked  by  a  set  of 
executable  tests.  If  these  units  are  not  operating  correctly,  validation 
testing  is  discontinued. 

Class  B  tests  check  that  a  conpiler  detects  illegal  language  usage.  Class  B 
tests  are  not  executable.  Each  test  in  this  class  is  coitpiled  and  the 
resulting  compilation  listing  is  examined  to  verify  that  all  violations  of 
the  Ada  Standard  are  detected.  Some  of  the  class  B  tests  contain  legal  Ada 
code  which  must  not  be  flagged  illegal  by  the  conpiler.  This  behavior  is 
also  verified. 

Class  L  tests  check  that  an  Ada  inplementation  correctly  detects  violation  of 
the  Ada  Standard  involving  multiple,  separately  compiled  units.  Errors  are 
expected  at  link  time,  and  execution  is  attempted. 

In  some  tests  of  the  ACVC,  certain  macro  strings  have  to  be  replaced  by 
implementation-specific  values  —  for  example,  the  largest  integer.  A  list 
of  the  values  used  for  this  implementation  is  provided  in  Appendix  A.  In 
addition  to  these  anticipated  test  modifications,  additional  changes  may  be 
required  to  remove  xinforeseen  conflicts  between  the  tests  and 
implementation-dependent  characteristics.  The  modifications  recpaired  for 
this  implementation  are  described  in  section  2.3. 
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For  each  Ada  inplementation,  a  customized  test  suite  is  produced  by  the  AVF. 
This  customization  consists  of  making  the  modifications  described  in  the 
preceding  paragraph,  removing  withdrawn  tests  (see  section  2.1),  and  possibly 
removing  some  inapplicable  tests  (see  section  2.2  and  [UG89]). 

In  order  to  pass  an  ACVC  an  Ada  implementation  must  process  each  test  of  the 
customized  test  suite  according  to  the  Ada  Standard. 


1.4  DEFINITION  OF  TERMS 

Ada  Compiler  The  software  and  any  needed  hardware  that  have  to  be  added  to 
a  given  host  and  target  conpater  system  to  allow 
transformation  of  Ada  programs  into  executable  form  and 
execution  thereof. 

Ada  Compiler  The  means  for  testing  conpliance  of  Ada  inplementations. 
Validation  consisting  of  the  test  suite,  the  support  programs,  the  ACVC 
Capability  user's  guide  and  the  template  for  the  validation  summary 

(ACVC)  report. 

Ada  An  Ada  compiler  with  its  host  conpater  system  and  its 

Implementation  target  computer  system. 

Ada  Joint  The  part  of  the  certification  body  which  provides  policy  and 

Program  guidance  for  the  Ada  certification  system. 

Office  (AJPO) 

Ada  The  part  of  the  certification  body  vdiich  carries  out  the 

Validation  procedures  required  to  establish  the  conpliance  of  an  Ada 
Facility  (AVF)  implementation. 

Ada  The  part  of  the  certification  body  that  provides  technical 

Validation  guidance  for  operations  of  the  Ada  certification  system. 

Organization 
(AVO) 

Compliance  of  The  ability  of  the  implementation  to  pass  an  ACVC  version, 
an  Ada 

Implementation 

A  functional  unit,  consisting  of  one  or  more  computers  and 
associated  software,  that  uses  common  storage  for  all  or  part 
of  a  program  and  also  for  all  or  part  of  the  data  necessary 
for  the  execution  of  the  program;  executes  user-written  or 
user-designated  programs;  performs  user-designated  data 
manipulation,  including  arithmetic  operations  and  logic 
operations;  and  that  can  execute  programs  that  modify 
themselves  during  execution.  A  computer  system  may  be  a 
stand-alone  oonit  or  may  consist  of  several  inter-connected 
units. 


Computer 

System 
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Conformity 


Customer 


Declaration  of 
Conformance 


Host  Computer 
System 

Inapplicable 

test 

ISO 

LRM 


Operating 

System 


Target 

Computer 

System 

Validated  Ada 
Conpiler 

Validated  Ada 
Implementation 

Validation 


Withdravm 

test 


Fulfillment  by  a  product,  process,  or  service  of  all 
requirements  specified. 

An  individual  or  corporate  entity  vAio  enters  into  an  agreement 
with  an  AVF  vdiich  specifies  the  terms  and  conditions  for  AVF 
services  (of  any  kind)  to  be  performed. 

A  formal  statement  from  a  customer  assuring  that  conformity 
is  realized  or  attainable  on  the  Ada  inplementation  for  which 
validation  status  is  realized. 

A  confute r  system  \(diere  Ada  source  programs  are  transformed 
into  executable  form. 

A  test  that  contains  one  or  more  test  objectives  found  to  be 
irrelevant  for  the  given  Ada  implementation. 

International  Organization  for  Standardization. 

The  Ada  standard,  or  Language  Reference  Mauaual,  published  as 
ANSI/MIL-STD-1815A-1983  and  ISO  8652-1987.  Citations  from  the 
LRM  take  the  form  "<section>.<subsection>:<paragraph>." 

Software  that  controls  the  execution  of  programs  and  that 
provides  services  such  as  resource  allocation,  scheduling, 
input/output  control,  and  data  management.  Usually,  operating 
systems  are  predominantly  software,  but  partial  or  complete 
hardware  iirplementations  are  possible. 

A  computer  system  \diere  the  executable  form  of  Ada  programs 
are  executed. 


The  coitpiler  of  a  validated  Ada  implementation. 


An  Ada  implementation  that  has  been  validated  successfully 
either  by  AVF  testing  or  by  registration  (Pro95]. 

The  process  of  checking  the  conformity  of  an  Ada  compiler  to 
the  Ada  programming  language  and  of  issuing  a  certificate  for 
this  implementation. 

A  test  found  to  be  incorrect  and  not  used  in  conformity 
testing.  A  test  may  be  incorrect  because  it  has  an  invalid 
test  objective,  fails  to  meet  its  test  objective,  or  contains 
erroneous  or  illegal  use  of  the  Ada  programming  language. 
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CHAPTER  2 


IMPLEMENTATION  DEPENDENCIES 


2.1  WITHDRAWN  TESTS 

The  following  tests  have  been  withdrawn  by  the  AVO.  The  rationale  for 
withdrawing  each  test  is  available  from  either  the  AVO  or  the  AVF.  The 


publication  date 

for  this 

list  of  withdrawn  tests 

is  22  November 

1993. 

B27005A 

E28005C 

B28006C 

C32203A 

C34006D 

C35507K 

C35507L 

C35507N 

C35507O 

C35507P 

C35508I 

C35508J 

C35508M 

C35508N 

C35702A 

C35702B 

C37310A 

B41308B 

C43004A 

C45114A 

C45346A 

C45612A 

C45612B 

C45612C 

C45651A 

C46022A 

B49008A 

B49008B 

A54B02A 

C55B06A 

A74006A 

C74308A 

B83022B 

B83022H 

B83025B 

B83025D 

C83026A 

B83026B 

C83041A 

B85001L 

C86001P 

C94021A 

C97116A 

C98003B 

BA2011A 

CB7001A 

CB7001B 

CB7004A 

CC1223A 

BC1226A 

CC1226B 

BC3009B 

BD1B02B 

BD1B06A 

AD1B08A 

BD2A02A 

CD2A21E 

CD2A23E 

CD2A32A 

CD2A41A 

CD2A41E 

CD2A87A 

CD2B15C 

BD3006A 

BD4008A 

CD4022A 

CD4022D 

CD4024B 

CD4024C 

CD4024D 

CD4031A 

CD4051D 

CD5111A 

CD7004C 

ED7005D 

CD7005E 

AD7006A 

CD7006E 

AD7201A 

AD7201E 

CD7204B 

AD7206A 

BD8002A 

BD8004C 

CD9005A 

CD9005B 

CDA201E 

CE2107I 

CE2117A 

CE2117B 

CE2119B 

CE2205B 

CE2405A 

CE3111C 

CE3116A 

CE3118A 

CE3411B 

CE3412B 

CE3607B 

CE3607C 

CE3607D 

CE3812A 

CE3814A 

CE3902B 

2.2  INAPPLICABLE  TESTS 

A  test  is  inapplicable  if  it  contains  test  objectives  vdiich  are  irrelevant 
for  a  given  Ada  implementation.  Reasons  for  a  test's  inapplicability  may  be 
supported  by  documents  issued  by  the  ISO  and  the  AJPO  known  as  Ada 
Commentaries  and  commonly  referenced  in  the  format  Al-ddddd.  For  this 
implementation,  the  following  tests  were  determined  to  be  inapplicable  for 
the  reasons  indicated;  references  to  Ada  Commentaries  are  included  as 
appropriate. 
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The  following  201  tests  have  floating-point  type  declarations  requiring 
more  digits  than  SYSTEM.MAX_DIGITS: 


C24113L..Y  (14  tests) 
C35706L..Y  (14  tests) 
C35708L..Y  (14  tests) 
C45241L..Y  (14  tests) 
C45421L..Y  (14  tests) 
C45524L..Z  (15  tests) 
C45641L..Y  (14  tests) 


C35705L..Y  (14  tests) 
C35707L..Y  (14  tests) 
C35802L..Z  (15  tests) 
C45321L..Y  (14  tests) 
C45521L..Z  (15  tests) 
C45621L..Z  (15  tests) 
C46012L..Z  (15  tests) 


The  following  20  tests  check  for  the  predefined  type  liONG_INTEGER;  for 
this  inplementation,  there  is  no  such  type: 


C35404C 

C45502C 

C45613C 

C55B07A 


C45231C 

C45503C 

C45614C 

B55B09C 


C45304C 

C45504C 

C45631C 

B86001W 


C45411C 

C45504F 

C45632C 

C86006C 


C45412C 

C45611C 

B52004D 

CD7101F 


C35713D  and  B86001Z  check  for  a  predefined  floating-point  type  with  a 
name  other  than  FLOAT,  LONG_FLOAT,  or  SHORT_FLOAT;  for  this 
implementation,  there  is  no  such  type. 


C45531M. .P  and  C45532M. .P  (8  tests)  check  fixed-point  operations  for 
types  that  require  a  SYSTEM. MAX_MANTISSA  of  47  or  greater;  for  this 
implementation,  MAX_MANTISSA  is  less  than  47. 

C45624A. .B  (2  tests)  check  that  the  proper  exception  is  raised  if 
MACHINEjDVERFLCWS  is  FALSE  for  floating  point  types  and  the  results  of 
various  floating-point  operations  lie  outside  the  range  of  the  base 
type;  for  this  implementation,  MACHINE_OVERFLCWS  is  TRUE. 

B86001Y  uses  the  name  of  a  predefined  fixed-point  type  other  than  type 
DURATION;  for  this  implementation,  there  is  no  such  type. 

C96005B  uses  values  of  type  DURATION'S  base  type  that  are  outside  the 
range  of  type  DURATION;  for  this  iitplementation,  the  ranges  are  the 
same. 


CD1009C  checks  whether  a  length  clause  can  specify  a  non-default  size 
for  a  floating-point  type;  this  inplementation  does  not  support  such 
sizes. 


CD2A84A,  CD2A84E,  CD2A84I..J  (2  tests),  and  CD2A840  use  length  clauses 
to  specify  non-default  sizes  for  access  types;  this  implementation  does 
not  support  such  sizes. 

The  following  264  tests  check  operations  on  sequential,  text,  and  direct 
access  files;  this  implementation  does  not  support  external  files: 

CE2102A. .C  (3)  CE2102G..H  (2)  CE2102K  CE2102N. .Y  (12) 
CE2103C..D  (2)  CE2104A..D  (4)  CE2105A. .B  (2)  CE2106A.  .B  (2) 
CE2107A..H  (8)  CE2107L  CE2108A..H  (8)  CE2109A.  .C  (3) 
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CE2110A.  .D 

(4) 

CE2111A. .1 

(9) 

CE2115A.  .B 

(2) 

CE2120A. .B 

(2) 

CE2201A. .C 

(3) 

EE2201D. .E 

(2) 

CE2201F..N 

(9) 

CE2203A 

CE2204A. .D 

(4) 

CE2205A 

CE2206A 

CE2208B 

CE2401A. .C 

(3) 

EE2401D 

CE2401E..F 

(2) 

EE2401G 

CE2401H. .L 

(5) 

CE2403A 

CE2404A. .B 

(2) 

CE2405B 

CE2406A 

CE2407A.  .B 

(2) 

CE2408A.  .B 

(2) 

CE2409A. .B 

(2) 

CE2410A. .B 

(2) 

CE2411A 

CE3102A. .C 

(3) 

CE3102F. .H 

(3) 

CE3102J. .K 

(2) 

CE3103A 

CE3104A. .C 

(3) 

CE3106A. .B 

(2) 

CE3107B 

CE3108A.  .B 

(2) 

CE3109A 

CE3110A 

CE3111A. .B 

(2) 

CE3111D..E 

(2) 

CE3112A.  .D 

(4) 

CE3114A. .B 

(2) 

CE3115A 

CE3119A 

EE3203A 

EE3204A 

CE3207A 

CE3208A 

CE3301A 

EE3301B 

CE3302A 

CE3304A 

CE3305A 

CE3401A 

CE3402A 

EE3402B 

CE3402C..D 

(2) 

CE3403A. .C 

(3) 

CE3403E. .F 

(2) 

CE3404B. .D 

(3) 

CE3405A 

EE3405B 

CE3405C. .D 

(2) 

CE3406A. .D 

(4) 

CE3407A. .C 

(3) 

CE3408A. .C 

(3) 

CE3409A 

CE3409C..E 

(3) 

EE3409F 

CE3410A 

CE3410C..E 

(3) 

EE3410F 

CE3411A 

CE3411C 

CE3412A 

EE3412C 

CE3413A. .C 

(3) 

CE3414A 

CE3602A.  .D 

(4) 

CE3603A 

CE3604A.  .B 

(2) 

CE3605A.  .E 

(5) 

CE3606A.  .B 

(2) 

CE3704A. .F 

(6) 

CE3704M. .0 

(3) 

CE3705A. .E 

(5) 

CE3706D 

CE3706F. .G 

(2) 

CE3804A. .P 

(16) 

CE3805A.  .B 

(2) 

CE3806A.  .B 

(2) 

CE3806D. .E 

(2) 

CE3806G. .H 

(2) 

CE3904A.  .B 

(2) 

CE3905A.  .C 

(3) 

CE3905L 

CE3906A. .C 

(3) 

CE3906E..F 

(2) 

CE2103A,  CE2103B,  and  CE3107A  use  an  illegal  file  name  in  an  attempt  to 
create  a  file  and  expect  NAME_ERROR  to  be  raised;  this  iirplementation 
does  not  support  external  files  and  so  raises  USE  ERROR.  (See  section 
2.3.) 


2.3  TEST  MODIFICATIONS 

Modifications  (see  section  1.3)  were  required  for  24  tests. 

The  following  tests  were  split  into  two  or  more  tests  because  this 
implementation  did  not  report  the  violations  of  the  Ada  Standard  in  the  way 
expected  by  the  original  tests. 

B24009A  B33301B  B38003A  B38003B  B38008B  B38009B 
B85008G  B85008H  BC1303F  BC3005B  BD2B03A  BD2D03A 
BD4003A 

CD1009A,  CD1009I,  CD1C03A,  CD2A22J,  CD2A31A. .C  (3  tests)  were  graded  passed 
by  Evaluation  Modification  as  directed  by  the  AVO.  These  tests  use 
instantiations  of  the  support  procedure  LENGTH_CHECK,  which  uses 
Unchecked_Conversion  according  to  the  interpretation  given  in  AI-00590.  The 
AVO  ruled  that  this  interpretation  is  not  binding  under  ACVC  1.11;  the  tests 
are  ruled  to  be  passed  if  they  produce  Failed  messages  only  from  the 
instances  of  LENGTH_CHECK — i.e,  the  allowed  Report. Failed  messages  have  the 
general  form: 

"  *  CHECK  ON  REPRESENTATION  FOR  <TYPE  ID>  FAILED." 
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AD9001B  was  graded  passed  by  Test  Modification  as  directed  by  the  AVO.  This 
test  checks  that  no  bodies  are  required  for  interfaced  subprograms;  among  the 
procedures  that  is  used  is  one  with  a  parameter  of  mode  OUT  (line  36).  This 
implementation  does  not  support  pragma  INTERFACE  for  procedures  with 
parameters  of  mode  OUT.  The  test  was  modified  by  commenting  out  line  36  and 
40;  the  modified  test  was  passed. 

CE2103A,  CE2103B,  and  CE3107A  were  graded  inapplicable  by  Evaluation 
Modification  as  directed  by  the  AVO.  The  tests  eibort  with  an  unhandled 
exception  vdien  USE  ERROR  is  raised  on  the  atteirpt  to  create  an  external  file. 
This  is  acceptable  behavior  because  this  inplementation  does  not  support 
external  files  (cf.  AI-00332). 
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CHAPTER  3 


PROCESSING  INFORMATIOJ 


3 . 1  TESTING  ENVIRONMENT 

The  Ada  inplementation  tested  in  this  validation  effort  is  described 
adequately  by  the  information  given  in  the  initial  pages  of  this  report. 

For  technical  and  sales  information  about  this  Ada  inplementation,  contact; 

Stewart  French 

Texas  Instruments,  Incorporated 
PO  Box  659305,  M/S  8496 
Plano,  TX  75086 
(214)  575-4272 


Testing  of  this  Ada  inplementation  was  conducted  at  the  customer's  site  by  a 
validation  team  from  the  AVF. 


3.2  SUMMARY  OF  TEST  RESULTS 

An  Ada  Implementation  passes  a  given  ACVC  version  if  it  processes  each  test 
of  the  customized  test  suite  in  accordance  with  the  Ada  Programming  Language 
Standard,  whether  the  test  is  applicable  or  inapplicable;  otherwise,  the  Ada 
Implementation  fails  the  ACVC  [Pro95]. 

For  all  processed  tests  (inapplicable  and  applicable),  a  result  was  obtained 
that  conforms  to  the  Ada  Programming  Language  Standard. 

The  list  of  items  below  gives  the  number  of  ACVC  tests  in  various  categories. 
All  tests  were  processed,  except  those  that  were  withdrawn  because  of  test 
errors  (item  b;  see  section  2.1),  those  that  require  a  floating-point 
precision  that  exceeds  the  implementation's  maximum  precision  (item  e;  see 
section  2.2),  and  those  that  depend  on  the  support  of  a  file  system —  if 
none  is  supported  (item  d).  All  tests  passed,  except  those  that  are  listed 
in  sections  2.1  and  2.2  (counted  in  items  b  and  f,  below). 
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PROCESSING  INFORMATION 


a)  Total  Number  of  /^plicable  Tests  3558 

b)  Total  Number  of  Withdrawn  Tests  104 

c)  Processed  Inapplicable  Tests  43 

d)  Non-Processed  I/O  Tests  264 

e)  Non-Processed  Floating-Point 

Precision  Tests  201 

f)  Total  Number  of  Inapplicable  Tests  508  (c+d+e) 


g)  Total  Number  of  Tests  for  ACVC  1.11  4170  (a+b+f) 


3.3  TEST  EXECUTIOJ 

A  magnetic  tape  containing  the  customized  test  suite  (see  section  1.3)  was 
taken  ^  on-site  by  the  validation  tesim  for  processing.  The  contents  of  the 
magnetic  tape  were  loaded  directly  onto  the  host  conf}uter. 

After  the  test  files  were  loaded  onto  the  host  conpiter,  the  full  set  of 
tests  was  processed  by  the  Ada  inplementation. 

The  tests  were  coitpiled  and  linked  on  the  host  con^juter  system,  as 
appropriate.  The  executable  images  were  transferred  to  the  target  computer 
system  by  the  IEEE-488,  and  run.  The  results  were  captured  on  the  host 
computer  system. 

Testing  was  performed  using  command  scripts  provided  by  the  customer  and 
reviewed  by  the  validation  team.  See  i^pendix  B  for  a  conplete  listing  of 
the  processing  options  for  this  iirplementation.  It  also  indicates  the 
default  options.  No  explicit  options  were  used  for  testing  this 
inplementation. 


Test  output,  conpiler  and  linker  listings,  and  job  logs  were  captured  on 
magnetic  tape  and  archived  at  the  AVF.  The  listings  examined  on-site  by  the 
validation  team  were  also  archived. 
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APPENDIX  A 


MACRO  PARAMETERS 


This  appendix  contains  the  macro  parameters  used  for  customizing  the  ACVC. 
The  meaning  and  purpose  of  these  parameters  are  explained  in  tUG89].  The 
parameter  values  are  presented  in  two  tables.  The  first  table  lists  the 
values  that  are  defined  in  terms  of  the  maximum  input-line  length,  which  is 
the  value  for  $MAX_IN_LEN — also  listed  here.  These  values  are  expressed  here 
as  Ada  string  aggregates,  vdiere  "V"  represents  the  maximum  input-line  length. 

Macro  Parameter  Macro  Value 


$MAX_IN_LEN  499  ~  Value  of  V 

$BIG_ID1  (1..V-1  =>  'A',  V  »=>  '1') 

$BIG_ID2  (1..V-1  =>  'A',  V  =>  '2') 

$BIG_ID3  (1..V/2  =>  'A')  Sc  '3'  & 

(1..V-1-V/2  =>  'A') 

$BIG_ID4  a..V/2  =>  'A')  &  '4'  & 

(1..V-1-V/2  =>  'A') 

$BIG_INT_LIT  (1..V-3  =>  '0')  &  "298" 

$BIG_REAL_LIT  (1..V-5  ->  '0')  &  "690.0" 

$BIG_STRING1  '"'Sc  (1..V/2  =>  'A')  Sc  '”' 

$BIG_STRING2  &  (1..V-1-V/2  =>  'A')  &  '1'  & 

$BLANKS  (1..V-20  =>  '  ' ) 

$MAX_LEN_INT_BASED_LlTERAL 

"2:"  &  (1..V-5  =>  '0')  Sc  "11:" 

$MAX_LEN_REAL_BASED_LITERAL 

"16:"  &  (1..V-7  =>  '0')  &  "F.E:" 
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$MAX_STRING_LITERAL  &  (1..V-2  =>  'A')  & 


The  following  table  lists  all  of  the  other  macro  parameters  and  their 
respective  values . 


Macro  Parameter  Macro  Value 


$ACC_SIZE 

32 

$ALIGNMENT 

4 

$COUNT_LAST 

2_147_483_647 

$DEFAULT_MEM_SIZE 

16_777_216 

$DEFAULT_STOR_UNIT 

8 

$DEFAULT_SYS_NAME 

MACS 

$DELTA_DOC 

0 . 0000000004656612873077392578125 

$ENTRY_ADDRESS 

SYSTEM. "+"(16) 

$ENTRY_ADDRESS1 

SYSTEM. "+"(17) 

$ENTRY_ADDRESS2 

SYSTEM. "+"(2) 

$FIELD_LAST 

2_147_483_647 

$FILE_TERMINATOR 

f  r 

$FIXED_NAME 

NO_SUCH_TYPE 

$FLQATJSIAME 

NO__SUCH_TYPE 

$FORM_STRING 

ti  II 

$FORM_STRING2 

”CAI^OT_RESTRICT_FILE_CAPACITO 

$GREATER  THAN  DURATION 

100_000.0 

$GREATER  THAN  DURATION  BASE  LAST 

T0_000_000.0 

$GREATER  THAN  FLOAT 

BASE  LAST 
l.^E+308 

$GREATER_THAN_FLCIAT 

SAFE  LARGE 

5.0E307 
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$GREATER_THAN_SHORT_FLQAT  SAFE_LARGE 

9.0E37 

$HIGH_PRIORITY  99 

$ILLEGAL_EXTERNAL_FILE_NAME1 

"/illegal/f  ile_naine/2 }  ]  $%FILE1 .  DAT" 

$ILLEGAL_EXTERNAL_FILE  NAME2 

'Villegal/file_naine/2}  J$%FILE2  .DAT" 

$INAPPROPRIATE_LINE_LENGTH 

-1 

$INAPPROPRIATE_PAGE_LENGTH 

-1 

$INCLUDE_PRAGMA1  PRAGMA  INCLUDE  ( "A28006D1 .TST" ) 

$INCLUDE_PRAGMA2  PRAGMA  INCLUDE  ( "B28006D1 .TST" ) 

$INTEGER_FIRST  -2147483648 

$INTEGER_LAST  2147483647 

$INTEGER_LAST_PLUS_1  2147483648 

$INTERFACE_LANGUAGE  C 

$LESS_THAN_DURATION  -100_000.0 

$LESS_THAN_DURATION_BASE_FIRST 

-10_000_000.0 

$LINE_TERMINATOR  ASCI I . LF 

$LCW_PRIORITY  0 

$MACHINE_CODE_STATEMENT 

CODE_0'(OP  ->  NOP); 

$MACHINE_CODE_TYPE  CODE_0 

$MANTISSA_DOC  31 

$MAX_DIGITS  15 

$MAX_INT  2147483647 

$MAX_INT_PLUS_1  2147483648 

$MIN_INT  -2147483648 

$NAME  TINY_INTEGER 
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$NAME_LIST 

$NAME_SPECIFICATIONl 

$NAME_SPECI FICATION2 

$NAME_SPECI FICATION3 

$NEG_BASED_INT 

$NEW_MEM_SIZE 

$NEW_STOR_UNIT 

$NEW_SYS_NAME 

$PAGE_TERMINATOR 

$RECORD_DEFINITION 

$RECORD_NAME 

$TASK_SIZE 

$TASK_STORAGE_SIZE 

$TICK 

$VARIABLE_ADDRESS 
$VARIABLE_ADDRESS1 
$VARIABLE_ADDRESS2 
$YOUR  PRACm 


MACS 

GEORGE$DUAl ; (VALIDATICW. 91-03-18-VRX. TESTS  JX2120A 
GEORGE$DUAl : [VALIDATION. 91-03-18-VRX. TESTS ]X2120B 
GEORGE$DUAl : [VALIDATIOJ. 91-03-18-VRX. TESTS ]X3119A 
16#F000000E# 

16_777_216 

8 

MACS 

ASCII. LF  &  ASCII. FF 

RECORD  SUBP:  OPERAND;  END  RECORD; 

CODE_0 

32 

1024 

0.01 

VAR_1 'ADDRESS 
VAR_2  'ADDRESS 
VAR  3 'ADDRESS 


PASSIVE 


APPEMJIX  B 


COMPILATION  SYSTEM  OPTICWS 


The  coitpiler  options  of  this  Ada  iitplementation,  as  described  in  this 
Appendix,  are  provided  by  the  customer.  Unless  specifically  noted  otherwise, 
references  in  this  appendix  are  to  coirpiler  documentation  and  not  to  this 
report . 
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VADSADA 


VADSADA  —  invoke  the  Ada  compiler 
Syntax 

VADS  ADA  [qualifiers]  [source_filel  . .  .  [object_file]  .  .  . 

Arguments 

objectjile  Non-Ada  object  fUenames.  These  files  are  passed  to  the  linker  and 

are  linked  with  the  specified  Ada  object  files. 

qualifiers  Qualifiers  to  the  compiler.  These  are: 

/APPEND  Must  be  used  with /OUTPUT.  It  Appends  output  to 

/DEBUG  Write  out  the  GNRX.LIB  file  in  ASCII. 

/DEFINE=(*identifientypc=value", ... ) 

Define  identifier  of  a  specified  type  and  value. 

/DEPEND  ENCIES  Analyze  for  dependencies  only;  no  link  is  performed  if  this 

qualifier  is  given  (/MAIN  and /OUTPUT  qualifiers  must  not  be 
used  with  this  qualifier). 

/ERRORS[-(oprion  {. ...])] 

Process  compilation  error  messages  using  the  ERROR  tool  and 
direct  the  output  to  SYSSOUTPUT;  the  parentheses  can  be  omitted 
if  only  one  qualifier  is  given  (by  default,  only  lines  containing 
errors  are  listed). 

Options: 

LISTING  List  entire  input  file. 

EDITORIs'cdifor"!  Insert  error  messages  into  the  source  file 
and  call  a  text  editor  (EDT  by  default). 
To  use  an  editor  other  than  EDT,  specify 
it  as  the  quoted  string  "editor^. 

OUTPUT[=/iIenamcl  Direct  error  processed  output  to  the 

specified  filename;  if  no  filename  is 
given,  the  source  filename  is  used  with  a 
Me  extension  .ERR. 

BRIEF  list  only  the  affected  lines  [defeult] 

Use  only  one  of  the  BRIEF,  LISTING,  OUTPUT  or  EDITOR 
options  in  a  single  command. 

/EXECUTABLE=/¥fenaifie 

Provide  an  explicit  name  for  the  executable  when  used  with  the 
/MAIN  qualifier;  the  filename  value  must  be  supplied  (if  the  file 
type  is  omitted,. VOX  is  assumed). 

fFlLE_LlST^lename  Compile  the  source  files  hsted  in  filename.  When 

/FILE_LIST^'fenaiiK  is  used,  source_file  is  not  required. 

/FULL.DIANA  Do  not  trim  the  DIANA  tree  before  output  to  net  files.  To  save  disk 
space,  the  DL\NA  tree  is  trimmed  so  that  aU  pointers  to  nodes  that 
did  not  involve  a  subtree  that  define  a  symbol  table  are  nulled 
(unless  those  nodes  are  part  of  the  body  of  an  inline  or  generic  or 
certain  other  values  that  are  retained  for  the  debugging  or 
compilation  information).  The  trimming  generally  removes  iiutial 
values  of  variables  and  all  statements. 

/GVAS_SUGGESTED 

Display  suggested  values  for  MIN_GVAS_ADDR  and 
MAXjGVAS_ADDR  INFO  directives. 
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/KEEPJL  Keep  the  intermediate  language  (IL)  file  produced  by  the  compiler 

front  end.  The  IL  file  is  placed  in  the  OBJECTS  directory,  with  the 
name  ADA^SOURCE.I. 

/LIBRARY=/i*brafy_name 

Operate  in  VAOS  library  library  jiame  (the  current  working 
directory  is  the  default) . 

/LINK_ARGUMENTS=^'i7altte" 

Pass  command  qualifiers  and  parameters  to  the  linker. 

/M  AIN[=Mnif.mim€l  Produce  an  executable  program  using  the  named  unit  as  the  main 
program;  if  no  value  is  given,  the  name  is  derived  from  the  first 
Ada  filename  parameter  (the  .A  suffix  is  removed);  the  executable 
filename  is  derived  from  the  main  program  name  unless  the 
/EXECUTABLE  qualifier  is  used. 

/NO_CODE_SHARING 

Compile  all  generic  instantiations  without  sharing  code  for  their 
bodies.  This  option  overrides  the  SHARE_BODY  INFO  directive 
and  the  SHAREXODE  or  SHARE^BODY  pragmas. 

/NOCONTROL  Suppress  "control"  messages  emitted  when  pragma  PAGE  and/or 

pragma  LIST  are  encountered. 

/NOOPTIMIZE  Do  not  optimize. 

/OPTIMIZEI=sni<mbefl 

Invoke  the  code  optimizer.  An  optional  digit  provides  the  level  of 
optimization.  /OPTlMIZE=4  is  the  default. 


/OPTIMIZE 

no  digit,  full  optimization 

/OPTIMIZE=0 

no  optimization 

/OPTIMIZE=l 

copy  propagation.  CONST  folding, 
removing  dean  variables,  subsuming 
moves  between  scalar  variables 

/OPTIMIZE=2 

add  common  subexpression  elimination 
within  basic  blocks 

/OPTIMIZERS 

add  global  common  subexpression 
elimination 

/OPTIMIZEr4 

add  hoisting  invariants  from  loops  and 
address  optimizations 

/optimizers 

add  range  optimizations  and  one  pass 
of  reducing  induction  expressions 

/OPTIMIZE=6 

add  unrolling  of  inner-most  loops 

/optimizer? 

add  one  more  pass  of  induction 
expression  reduction 

/optimizers 

add  one  more  pass  of  induction 
expression  reduction 

/OPTIMIZEr9 

add  one  more  pass  of  induction 
expression  reduction  and  add  hoisting 
expressions  common  to  the  then  and  the 
else  parts  of  if  statements 

/OUTPUT=^7e«amc  Direct  the  output  to  filename  (the  default  is  SYSSOUTPUT). 
/PRE_PROCESS  Invoke  the  Ada  Preprocessor.  VADS  APP 

/RECOMPILE_LIBRARY=VADSJibrflry 

Force  analysis  of  all  generic  instantiations  causing  reinstantiation  of 
any  that  are  out  of  date. 

/RECREATE_GVAS  Reinitialize  the  library's  GVAS  and  the  GVAS.TABLE  file  and  exit. 
No  compilations  are  performed . 
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Show  the  name  of  the  tool  executable  but  do  not  execute  it. 

Print  the  name  of  the  hont  end,  code  generator,  optimizer,  linker 
and  list  the  tools  that  are  invoked. 

Apply  pragma  SUPPRESS  for  all  checks  to  the  entire  compilation 
Print  timing  information  for  the  compilation. 

Print  information  for  the  compilation. 

Specify  display  of  warning  diagnostics  (Default:  AVARNINGS]. 
Name  of  the  source  file  to  compile. 

Description 

The  command  VADS  ADA  executes  the  Ada  compiler  and  compiles  the  named  Ada  source  file. 
The  file  must  reside  in  a  VADS  Ubrary  directory.  The  AD  A.LIB  file  in  this  directory  is  modified 
after  each  Ada  imit  is  compiled. 

By  default,  VADS  ADA  produces  only  object  and  net  files.  If  the  /MAIN  qualifier  is  used,  the 
compiler  automatically  invokes  VADS  LD  and  builds  a  complete  program  with  the  named  library 
unit  as  the  rrrain  program. 

The  compUer  generates  object  files  in  VOX  format. 

Non-Ada  object  files  can  be  given  as  arguments  to  VADS  ADA.  These  files  are  passed  on  to  the 
linker  and  are  linked  with  the  specified  Ada  object  files. 

Command  line  qualifiers  can  be  specified  in  any  order  but  the  order  of  compilation  and  the  order 
of  the  files  passed  to  the  linker  is  sigruficant. 

Several  VADS  compilers  may  be  simultaneously  available  on  a  single  system.  The  VADS  ADA 
command  within  any  version  of  VADS  on  a  system  executes  the  correct  compiler  components 
based  upon  visible  library  directives. 

Program  listings  with  a  disassembly  of  machine  code  instructions  are  generated  by  VADS  DB  or 
VADS  DAS. 

Diagnostics 

The  diagnostics  produced  by  the  VADS  compiler  are  self-explanatory.  Most  refer  to  the  RM.  Each 
RM  reference  includes  a  section  number  and  optionally,  a  paragraph  number  enclosed  in 
parentheses. 


/SHOW 

/SHOW_ALL 

/SUPPRESS 

/TIMING 

/VERBOSE 

/WARNINGS 

/NOWARNINGS 

soutcejile 


REFERENCES:  APP  Prog— 9 ,  VADS  APP  Ref— 30  /ERRORS  User— 42,.  Optimization  User— 40, 
pragma  OPTIMIZE_CODE(OFF)  Prog— 82,  .pragma  SUPPRESS(ALL_CHECKSProg— 84,  VOX 
format  Prog— 65,  VADS  DAS  Ref— 37,  VADS  DB  Ref— 39,  VADS  ERROR  Ref— 41,  VADS  LD 
Ref_53,  VADS  MKLIB  Ref— 62 
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LINKER  OPTIONS 

The  linker  options  of  this  Ada  inplementation,  as  described  in  this  Appendix, 
are  provided  by  the  customer.  Unless  specifically  noted  otherwise, 
references  in  this  appendix  are  to  linker  documentation  and  not  to  this 
report. 
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VADSLD 


prelinker 

Syntax 

VADS  LD  [gualifiers)  unit_name  [IinJcer_opticinsl 

Arguments 

linkerjoptions  All  arguments  after  unitjname  are  passed  on  to  the  linker.  These  arguments 
can  be  linker  options,  names  of  object  files  or  archive  libraries  or  library 
abbreviations. 

qualifiers  Qualifiers  to  the  VADS  LD  command.  These  are: 

/APPEND  Must  be  used  with  /OUTPUT.  It  Appends  output  to  filename. 

/EARLY="iinif_nam£" 

Force  the  given  imit  to  elaborate  as  early  as  possible  (unitjname 
must  be  enclosed  in  double  quotes) . 

fEXECUTABLEl^filename] 

Put  the  output  in  the  named  file.  The  default  executable  names  are 
<mainjumt>.EXE  on  self  hosts  or  <mainjunit>,\ OX  on  cross 
targets. 

/files  Print  a  list  of  dependent  files  in  elaboration  order  and  suppress 

linking. 

/LIBRARY=lihrafy_name 

Collect  iixf ormation  required  for  linking  in  libraryjname  instead  of 
the  current  directory.  However,  place  the  executable  in  the  current 
directory. 

/LINK_ARGS^FILE=fikname 

Read  list  of  options  and/or  object  files  to  be  passed  to  the  VMS 
linker  from  file  filename.  This  option  is  used  when  the  number  or 
length  of  the  arguments  is  so  large  that  it  caimot  fit  on  the  VMS 
command  line.  In  filenamer  the  arguments  can  be  listed  one  per 
line  or  there  can  be  multiple  arguments  on  one  line.  Any  number 
of  spaces  and/or  blank  lines  can  delimit  each  argument.  This 
option  can  be  used  in  conjunction  with  /LINK_OPTIONS. 

/LINK^OPTIONS==o57CctJi7c_or^<Itfali/icft...l" 

Add  the  options  surrounded  by  quotes  to  the  invocation  of  the 
lirdcer. 

/OUTPUT=/f /cname  Direct  output  to  filename.  Default  is  SYSSOUTPUT. 

/SHOW 
/TABLE 
/UNITS 
/VERBOSE 

/VERIFY 
/WARNINGS 
unitjname  Name  of  an  Ada  unit. 

Description 

VADS  LD  collects  the  object  files  needed  to  make  unitjname  a  main  program  and  calls  the  xlink 
liidcer  to  liidc  together  all  Ada  and  other  language  objects  required  to  produce  an  executable. 
unitjname  must  be  a  non-generic  subprogram  that  is  either  a  procedure  or  a  function  that  returns 
an  Ada  STANDARD.INTEGER  (the  predefined  type  INTEGER).  The  utility  uses  the  net  files 
produced  by  the  Ada  compiler  to  check  dependency  information.  VADS  LD  produces  an 
exception  mapping  table,  a  unit  elaboration  table  and  passes  this  information  to  the  liiiker.  The 


Show  the  name  of  the  tool  executable  but  do  not  execute  it. 

List  the  symbols  in  the  elaboration  table  to  standard  output. 
Print  a  list  of  dependent  uiuts  in  order  and  suppress  linking. 

Generate  an  options  file,  usable  by  the  cross  linker,  that  has  the 
name  of  the  executable  but  with  the  extension  .OPT 

Print  the  VMS  linker  command  but  suppress  execution. 
Suppress  warning  messages. 
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elaboration  list  generated  by  VADS  LD  does  not  include  library  level  packages  that  do  not  need 
elaboration.  Similarly,  packages  that  contain  no  code  that  raises  an  exception  no  longer  have 
exception  tables. 


VADS  LD  reads  instructions  for  generating  executables  from  the  ADA.LIB  pe  ui  toe  VADS 
libraries  on  the  search  list.  Besides  information  generated  by  the  compiler,  these  duecbves  mdi^ 
WITHn  directives  automatically  link  object  modules  compiled  from  other  lan^wges  ot  Ada  ob^c 
modules  not  named  in  context  clauses  in  the  Ada  source.  Any  number  of  WTH  di^bves  can  be 
placed  in  a  library  but  they  must  be  numbered  contiguously  beginning  at  WITHl.  The  directives 
are  recorded  in  the  Ubrarv-s  ADA.L1B  file  and  have  the  folloiving  form: 


WITHl I  LINK  I  Ob ject_fiie  I 
WITH2  I  LINK!  archive_fiie  / 

WITH  directives  can  be  placed  in  the  local  Ada  libraries  or  in  any  VADS  library  on  the  search  list. 

A  WITH  directive  in  a  local  VADS  library  or  earlier  on  the  library  search  list  hides  the  same 
numbered  WITH  directive  in  a  Ubrary  later  in  the  Ubrary  search  Ust. 

Use  VADS  INFO  to  change  or  report  library  directives  in  the  current  library. 


Diagnostics 


Self-explanatory  diagnostics  are  produced  for  missing  files,  etc.  Occasional  additional  messages 
are  produced  by  the  linker. 


Files 


Normally,  VADS  LD  generates  an  intermediate  file  with  the  process  ID  as  a  substring, 
VADSOPTION<proass_ID>.OPT. 

With  either  the  A^ERIFY  or  A^ERBOSE  qualifiers,  however,  VADS  LD  produces  the  intermediate 
file,  <main_unit>.0?T. 


APPENDIX  C 


APPENDIX  F  OF  THE  Ada  STANDARD 


The  only  allowed  iirplementation  dependencies  correspond  to 
implementation-dependent  pragmas,  to  certain  machine-dependent  conventions  as 
mentioned  in  Chapter  13  of  the  Ada  Standard,  eind  to  certain  allowed 
restrictions  on  representation  clauses-  The  implementation-dependent 
characteristics  of  this  Ada  in^lementation,  as  described  in  this  Appendix, 
are  provided  by  the  customer.  Unless  specifically  noted  otherwise, 
references  in  this  Appendix  are  to  compiler  documentation  and  not  to  this 
report.  Implementation-specific  portions  of  the  package  STANDARD,  vdiich  are 
not  a  part  of  Appendix  F,  are: 


package  STANDARD  is 


type  INTEGER  is  range  -2147483648  ..  2147483647; 

type  SHORT_INTEGER  is  range  -32768  ..  32767; 

type  TINY_INTEGER  is  range  -128  ..  127; 

type  LONG  FLOAT  is  digits  15  range 

-1.79769313486232E+308  ..  +1.79769313486232E+308; 

type  FLOAT  is  digits  6  range 
-3.40282E+38  ..  3.40282E+38; 

type  SHORT  FLOAT  is  digits  6  range 
-3.4028IE+38  ..  3.40282E+38; 

type  DURATION  is  delta  0.0001  range 
-214748.3648  ..  214748.3647; 

end  STANDARD; 
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Appendix  F 

Implementation  Dependencies 


This  chapter  defines  the  implementation-dependent  characteristics  of  the  RTE  as  required 
by  MIL-STD-1815A,  Appendix  F.  The  VADS  compiler  provides  these  features: 

•  shared  generic  bodies 

•  all-Ada  run  time  system 

•  representation  clauses  to  the  bit  level  and  pragma  PACK  (Ada  RM  13.1) 

•  length  clauses  and  unsigned  types  (8-  and  16-bit)  (Ada  RM  13.2) 

•  enumeration  representation  clauses  (Ada  RM  13.3) 

•  record  representation  clauses  (Ada  RM  13.4) 

•  interrupt  entries  (Ada  RM  13.5.1) 

•  representation  attributes  (Ada  RM  13.7.2) 

•  machine  code  insertions  and  pragma  IMPLICIT_CODE  (Ada  RM  13.8) 

•  interface  programming  features,  including  pragma  INTERFACE,  pragma  EXTER¬ 
NAL-NAME,  pragma  EXTERNAL,  pragma  INTERFACE-NAME,  WITH  directives, 
VADS  INFO,  and  external  dependencies  capabilities  (Ada  RM  13.9) 

•  unchecked  deallocations  (Ada  RM  13.10.1) 

•  unchecked  conversions  (Ada  RM  13.10.2) 

•  pool-based  memory  allocation  option 

F.l  Implementation-Dependent  PRAGMAS 

Each  of  this  implementation’s  pragmas  is  briefly  described  here.  Additional  information  on 
some  of  these  pragmas  is  found  under  discussions  of  particular  language  constructs. 
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F.1.1  PRAGMA  alignment 

PRAGMA  alignment(object,  powerjof_2_byte.alignment)  (VADScross  only) 

allows  the  user  to  specify  alignment  for  objects  declared  in  a  package  specifica¬ 
tion  or  body. 

F.1.2  PRAGMA  builtJn 

PRAGMA  builtin 

may  be  used  in  some  parts  of  the  code  for  TEXTJO,  MACHINE_CODE,  UN- 
CHECKED.CONVERSION,  UNCHECKED  JDEALLOCATION  and  lower  level 
support  packages  in  STANDARD.  It  is  reserved  and  cannot  be  accessed  directly. 

F.1.3  PRAGMA  controlled 

PRAGMA  controlled 

is  recognized  by  the  implementation  but  has  no  effect  in  the  current  release. 

F.1.4  PRAGMA  elaborate 

PRAGMA  elaborate 

is  implemented  as  described  in  Appendix  B  of  the  Ada  RM. 

F.1.5  PRAGMA  external 

PRAGMA  external(language,  subprogram) 

supports  calling  Ada  subprograms  from  foreign  languages.  The  compiler  gener¬ 
ates  code  for  the  subprogram  that  is  compatible  with  the  calling  conventions  of 
the  foreign  language.  The  subprogram  may  also  be  called  from  Ada  normally. 
The  supported  languages  and  restrictions  on  parameter  and  result  types  are  the 
same  as  for  pragma  INTERFACE.  This  pragma  only  has  an  effect  when  the 
calling  conventions  of  the  foreign  language  differ  from  those  of  Ada. 

F.1.6  PRAGMA  external_name 

PRAGMA  external_name(subprogram,  link_name) 

allows  the  user  to  specify  a  link  for  an  Ada  variable  or  subprogram  so  that  the 
object  can  be  referenced  from  other  languages.  The  PRAGMA  is  allowed  at 
the  place  of  a  declarative  item  in  a  package  specification  and  must  apply  to  an 
object  declared  earlier  in  the  same  package  specification. 

Objects  must  be  variables  defined  in  a  package  specification;  subprograms  can 
be  either  library  level  or  within  a  package  specification. 

This  pragma  is  allowed  with  inline  subprograms  but  disallowed  with  inlinejonly 
subprograms.  It  also  cannot  be  used  on  objects  created  by  renaming  declara¬ 
tions. 
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F.1.7  PRAGMA  implicit.code 

PRAGMA  implicit jcode 

The  IMPLICIT.CODE  pragma  specifies  that  implicit  code  generated  by  the 
compiler  is  allowed  (ON)  or  disallowed  (OFF)  and  is  used  only  within  the 
declarative  part  of  a  machine  code  procedure.  Implicit  code  includes  pream¬ 
ble  and  trailer  code  (e.g.,  code  used  to  move  parameters  from  and  to  the  stack). 
Use  of  PRAGMA  implicit_code  does  not  eliminate  code  generated  for  run  time 
checks  nor  does  it  eliminate  caU/return  instructions.  These  can  be  eliminated 
by  PRAGMA  suppress  and  PRAGMA  inline,  respectively.  A  warning  is  issued 
if  OFF  is  used  and  any  implicit  code  needs  to  be  generated.  This  pragma  should 
be  used  with  caution. 

F.1.8  PRAGMA  initialize 

PRAGMA  initialize(static  |  dynamic) 

when  placed  in  a  library-level  package,  spec  or  body;  causes  all  objects  in  the 
package  to  be  initialized  as  indicated,  statically  or  dynamically.  Only  library- 
level  objects  are  subject  to  static  initialization.  AU  objects  within  procedures 
are,  by  definition,  dynamic. 

If  PRAGMA  initialize(static)  is  used  and  an  object  cannot  be  initialized  stati¬ 
cally,  code  will  be  generated  to  initialize  the  object  and  a  warning  message  will 
be  generated. 

F.1.9  PRAGMA  inline 
PRAGMA  inline 

is  implemented  as  described  in  Appendix  B  of  the  Ada  RM  with  the  addition 
that  recursive  calls  can  be  expanded  with  the  pragma  up  to  the  maximum  depth 
of  4.  Warnings  are  produced  for  bodies  that  are  not  available  for  inline  expan¬ 
sion.  PRAGMA  inline  is  ignored  and  a  warning  is  issued  when  it  is  applied  to 
subprograms  which  declare  tasks,  packages,  exceptions,  types  or  nested  subpro¬ 
grams. 

F.1.10  PRAGMA  inline.only 

PRAGMA  inlinejonly 

when  used  in  the  same  way  as  PRAGMA  inline,  indicates  to  the  compiler  that 
the  subprogram  must  always  be  in-lined  (very  important  for  some  code  pro¬ 
cedures.).  This  pragma  also  suppresses  the  generation  of  a  callable  version 
of  the  routine  which  saves  code  space.  If  a  user  erroneously  makes  an  IN¬ 
LINE-ONLY  subprogram  recursive,  a  warning  message  will  be  emitted  and  a 
PROGRAM-ERROR  will  be  raised  at  run  time. 
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F.1.11  PRAGMA  interface 

PRAGMA  interface  (language,  subprogram) 

supports  calls  to  ADA,  C,  PASCAL,  FORTRAN  and  UNCHECKED  language 
functions.  The  Ada  specifications  can  be  either  functions  or  procedures.  This 
pragma  can  also  be  used  to  call  code  written  in  unspecified  languages  using 
UNCHECKED  for  the  language  name. 

For  ADA,  the  compiler  will  generate  the  call  as  if  it  were  to  an  Ada  procedure 
but  wiU  not  expect  a  matching  procedure  body. 

For  C,  the  types  of  parameters  and  the  result  type  for  functions  must  be  scalar, 
access  or  the  predefined  type  ADDRESS  in  SYSTEM.ADDRESS.  Record  and 
array  objects  can  be  passed  by  reference  using  the  ’ADDRESS  attribute.  All 
parameters  must  have  mode  IN. 

For  PASCAL,  the  types  of  parameters  and  the  result  type  for  functions  must  be 
scalar,  access  or  the  predefined  type  ADDRESS  in  SYSTEM.ADDRESS.  Record 
and  array  objects  can  be  passed  by  reference  using  the  ADDRESS  attribute. 

For  FORTRAN,  all  parameters  are  passed  by  reference;  the  parameter  types 
must  have  type  SYSTEM.ADDRESS.  The  result  type  for  a  FORTRAN  function 
must  be  a  scalar  type. 

UNCHECKED  may  be  used  to  interface  to  an  unspecified  language,  such  as 
assembler.  The  compiler  will  generate  the  call  as  if  it  were  to  an  Ada  procedure 
but  will  not  expect  a  matching  Ada  procedure  body. 


F.1.12  PRAGMA  interface_name 

PRAGMA  interface_name(ada_name,  link_name) 

with  the  parameters  allows  variables  or  subprograms  defined  in  another  language 
to  be  referenced  directly  in  Ada.  It  replaces  all  occurrences  of  Adajiame  with 
an  external  reference  to  linkjiame  in  the  object  file  using  the  syntax: 

PRAGMA  interface-name  (Ada_name,  link-name); 

If  Ada-name  denotes  an  object,  the  pragma  is  allowed  at  the  place  of  a  declara¬ 
tive  item  in  a  package  specification  and  must  apply  to  an  object  declared  earlier 
in  the  same  package  specification.  The  object  must  be  declared  as  a  scalar  or 
an  access  type.  The  object  cannot  be  any  of  the  following. 

•  loop  variable 

•  constant 

•  initialized  variable 

•  array 

•  record 
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If  Adajiame  denotes  a  subprogram,  a  PRAGMA  interface  must  have  already 
been  specified  for  the  subprogram. 

The  link_name  must  be  constructed  as  expected  by  the  linker.  For  example, 
some  C  compilers  and  linkers  preface  the  C  variable  name  with  an  underscore. 
Such  conventions  are  defined  in  package  LANGUAGE.  The  following  example 
makes  the  C  global  variable  errno  available  within  an  Ada  program: 

with  LANGUAGE; 
package  PACKAGE.NAME  is 

ERRNO : INTEGER; 

PRAGMA  interface.name  (ERRNO, LANGUAGE. C.PREFIX  &  "errno"); 
end  PACKAGE.NAME; 

F.1.13  PRAGMA  link.with 

PRAGMA  link.with 

can  be  used  to  pass  arguments  to  the  target  linker.  It  may  appear  in  any 
declarative  part  and  accepts  one  argument,  a  constant  string  expression.  This 
argument  is  passed  to  the  target  linker  whenever  the  unit  containing  the  pragma 
is  included  in  a  link. 

If  the  constant  string  expression  begins  with  the  string  is  left  untouched. 

F.1.14  PRAGMA  list 

PRAGMA  list 

is  implemented  as  described  in  Appendix  B  of  the  Ada  RM. 

F.1.15  PRAGMA  memory  .size 

PRAGMA  memory  .size 

is  recognized  by  the  implementation  but  has  no  effect  in  the  current  release. 
The  implementation  does  not  allow  package  SYSTEM  to  be  modified  by  means 
of  pragmas;  it  must  be  recompiled. 

F.1.16  PRAGMA  noJmage 

PRAGMA  noJmage 

suppresses  the  generation  of  the  image  array  used  for  the  IMAGE  attribute  of 
enumeration  types.  This  eliminates  the  overhead  required  to  store  the  array 
in  the  executable  image.  An  attempt  to  use  the  IMAGE  attribute  on  a  type 
whose  image  array  has  been  suppressed  will  result  in  a  compilation  warning  and 
PROGRAM-ERROR  raised  at  run  time. 
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F.1.17  PRAGMA  non_reentrant 

PRAGMA  non_reentrant(subprogram) 

takes  one  argument  which  can  be  the  name  of  a  library  subprogram  or  a  subpro¬ 
gram  declared  immediately  within  a  library  package  specification  or  body.  This 
pragma  indicates  to  the  compiler  that  the  subprogram  wifi,  not  be  called  recur¬ 
sively  allowing  the  compiler  to  perform  specific  optimizations.  The  pragma  can 
be  applied  to  a  subprogram  or  a  set  of  overloaded  subprograms  within  a  package 
specification  or  package  body. 

F.1.18  PRAGMA  not -elaborated 
PRAGMA  not_elaborated 

suppresses  the  generation  of  elaboration  code  and  issues  warnings  if  elaboration 
code  is  required.  It  indicates  that  the  package  will  not  be  elaborated  because 
it  is  either  part  of  the  RTS,  a  configuration  package  or  an  Ada  package  that 
is  referenced  from  a  language  other  than  Ada.  It  can  appear  only  in  a  library 
package  specification. 

F.1.19  PRAGMA  optimize 

PRAGMA  optimize 

is  recognized  by  the  implementation  but  has  no  effect  in  the  current  release. 

F.1.20  PRAGMA  optimize.code 

PRAGMA  optimize_code(off  |  on) 

specifies  whether  the  code  should  be  optimized  (ON)  by  the  compiler  or  not 
(OFF).  It  can  be  used  in  any  subprogram.  When  OFF  is  specified,  the  compiler 
generates  unoptimized  code.  The  default  is  ON. 

Optimization  can  be  selectively  suppressed  using  this  pragma  at  the  subpro¬ 
gram  level.  Inline  subprograms  are  optimized  even  if  they  have  PRAGMA  op- 
timize_code(off)  unless  the  caller  also  hcis  PRAGMA  optimize_code(off). 

F.1.21  PRAGMA  pack 

PRAGMA  pack 

will  cause  the  compiler  to  minimize  gaps  between  components  in  the  represen¬ 
tation  of  composite  types.  Objects  larger  than  a  single  STORAGE-UNIT  are 
packed  to  the  nearest  STORAGE-UNIT. 

F.1.22  PRAGMA  page 

PRAGMA  page 

is  implemented  as  described  in  Appendix  B  of  the  Ada  RM.  It  is  also  recognized 
by  the  source  code  formatting  tool  VADS  PR  (VMS). 
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F.1.23  PRAGMA  passive 

PRAGMA  passive  is  not  implemented  in  the  MACS  RTE.  Refer  to  the  CIFO  PRAGMA 
thread_of_controI  described  in  the  other  portions  of  the  MACS  SUM. 


F.1.24  PRAGMA  priority 

PRAGMA  priority 

is  implemented  as  described  in  Appendix  B  of  the  Ada  RM.  The  allowable  range 
for  pragma  PRIORITY  is  0  ..  99. 


F.1.25  PRAGMA  rtsJnterface 

PRAGMA  rtsJnterface(rtsjoutine,  user_routine) 

allows  for  the  replacement  of  the  default  calls  made  implicitly  at  run-time  to  the 
underlying  RTS  routines.  You  can  cause  the  compiler  to  generate  calls  to  any 
routine  of  your  choosing  as  long  as  its  parameters  and  RETURN  value  match 
the  original.  Use  this  pragma  with  caution. 


F.1.26  PRAGMA  share_code 

PRAGMA  share_code(generic  unit /instantiation, boolean)  provides  for  the  shar¬ 
ing  of  object  code  between  multiple  instantiations  of  the  same  generic  sub¬ 
program  or  package  body.  A  ‘parent’  instantiation  is  created  and  subsequent 
instantiations  of  the  same  types  can  share  the  parent’s  object  code,  reducing 
program  size  and  compilation  times. 

The  SHARE.CODE  pragma  takes  the  name  of  a  generic  instantiation  or  a 
generic  unit  as  the  first  argument  and  either  one  of  the  identifiers  TRUE  or 
FALSE  as  a  second  argument.  When  the  first  argument  is  a  generic  unit,  the 
pragma  applies  to  all  instantiations  of  that  generic.  When  the  first  argument 
is  the  name  of  a  generic  instantiation,  the  pragma  applies  only  to  the  specified 
instantiation  or  overloaded  instantiations. 

If  the  second  argument  is  TRUE,  the  compiler  will  try  to  share  code  generated 
for  a  generic  instantiation  with  code  generated  for  other  instantiations  of  the 
same  generic.  When  the  second  argument  is  FALSE  each  instantiation  will  get 
a  unique  copy  of  the  generated  code. 

The  extent  to  which  code  is  shared  between  instantiations  depends  on  this 
pragma  and  the  kind  of  generic  formal  parameters  declared  for  the  generic  unit. 
It  is  only  allowed  immediately  at  the  place  of  a  declarative  item  in  a  declarative 
part  or  package  specification  or  after  a  library  unit  in  a  compilation  but  before 
any  subsequent  compilation  unit. 

The  name  PRAGMA  share-body  may  be  used  instead  of  share_code  with  the 
same  effect. 
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F.1.27  PRAGMA  shared 

PRAGMA  shared  is  recognized  by  the  implementation  but  has  no  effect  in  the 
current  release. 

F.1.28  PRAGMA  storage_unit 

PRAGMA  storage.unit  is  recognized  by  the  implementation  but  has  no  effect  in 
the  current  release.  The  implementation  does  not  allow  SYSTEM  to  be  modified 
by  means  of  pragmas.  However,  the  same  effect  can  be  achieved  by  recompiling 
package  SYSTEM  with  altered  values. 

F.1.29  PRAGMA  suppress 

PRAGMA  suppress 

is  implemented  as  described  in  Appendix  B  of  the  Ada  RM  except  that  DIVI- 
SION.CHECK  and  in  some  cases  OVERFLOW_CHECK,  cannot  be  suppressed. 

The  use  of  PRAGMA  suppress(alLchecks)  is  equivalent  to  writing  at  the  same 
point  in  the  program  a  suppress  pragma  for  each  of  the  checks  listed  in  RM  11.7. 

The  pragma  SUPPRESS(EXCEPTION_TABLES)  informs  the  code  generator 
that  the  tables  normally  generated  to  identify  exception  regions  are  not  to  be 
generated  for  the  enclosing  compilation  unit.  This  reduces  the  size  of  the  static 
data  required  for  a  unit  but  also  disables  exception  handling  within  that  unit. 

F.1.30  PRAGMA  system_name 

PRAGMA  systemjiame 

is  recognized  by  the  implementation  but  has  no  effect  in  the  current  release.  The 
implementation  does  not  allow  SYSTEM  to  be  modified  by  means  of  pragmas. 
However,  the  file  system.a  from  the  STANDARD  library  can  be  copied  to  a  local 
VADS  library  and  recompiled  there  with  new  values. 

F.1.31  PRAGMA  unchecked_subprogram_invocation 
PRAGMA  unchecked jsubprogramJnvocation 
is  TBD. 

F.1.32  PRAGMA  volatile 

PRAGMA  volatile(object) 

guarantees  that  loads  and  stores  to  the  named  object  will  be  performed  as 
expected  after  optimization. 

The  object  declaration  and  the  pragma  must  both  occur  (in  this  order)  imme¬ 
diately  within  the  same  declarative  part  or  package  specification. 
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F.1.33  PRAGMA  warnings 

PRAGMA  warnings  (on  |  off) 

selectively  suppress  warnings  on  a  single  statement  or  a  group  of  statements. 

PRAGMA  warnings  (off);  statement(s)  that  generate  warnings;  PRAGMA  warn¬ 
ings  (on); 


F.2  Predefined  Packages  And  Generics 

The  following  predefined  Ada  packages  given  by  Ada  RM  Appendix  C(22)  are  provided  in 
the  STANDARD  library.  For  VADScross  products,  they  are  zdso  provided  in  the  CROSS  JO 
library. 

.  generic  function  UNCHECKED.CONVERSION 

•  generic  package  DIRECT  JO 

•  generic  package  SEQUENTIALJO 

•  generic  procedure  UNCHECKED J)EALLOCATION 

•  package  CALENDAR 

•  package  lOJEXCEPTIONS 

•  package  LOWXEVELJO 

•  package  MACHINE.CODE 

•  package  STANDARD 

•  package  SYSTEM 

•  package  TEXT  JO 

F.2.1  package  SYSTEM 

package  SYSTEM 

The  following  is  the  package  specification  for  package  SYSTEM: 


RESTRICTED  RIGHTS  LEGEND 

Use,  duplication,  or  disclosure  by  the  Government  is 
subject  to  restrictions  as  set  forth  in  subparagraph 
(c)(1) (ii)  of  the  Rights  in  Technical  Data  and  Computer 
Software  Clause  at  DFARS  252.227-7013. 

Texas  Instruments,  Inc. 


6620  Chase  Oaks  Blvd 
Plano,  TX  75023 
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—  I  Copyright  (c)  1992  Texas  Instruments,  Inc. 

—  I  All  Rights  Reserved. 


with  UHSIGHED.TYPES; 

package  SYSTEM  is 

pragma  SUPPRESS (ALL_CHECKS) ; 

pragma  SUPPRESS (EXCEPTIOI.TABLES ) ; 

pragma  »0T_ELAB0RATED; 

type  MANE  is  (  MACS  ); 

SYSTEN.HAME  ;  constant  NAME  :=  MACS; 
STORAGE.UMIT  :  constant  :=  8; 
MEMORY_SIZE  :  constant  :=  16_777_216; 

System-Dependent  Named  Numbers 
MIN.INT  :  constant  :=  -2_147_483_648; 
MAX_INT  :  constant  :=  2_147_483_647; 
MAX_DIGITS  :  constant  :=  15; 
NAX_MANTISSA  :  constant  :=  31; 
FIME_DELTA  :  constant  :=  2.0**(-31); 
TICK  :  consteuit  :=  0.01; 


Other  System-dependent  Declarations 
subtype  PRIORITY  is  INTEGER  range  0  . .  99; 

MAX_REC_SIZE  :  integer  :=  64*1024; 
type  ADDRESS  is  private; 

function  (A:  ADDRESS;  B:  ADDRESS)  return  BOOLEAN; 

function  "<"  (A:  ADDRESS;  B:  ADDRESS)  return  BOOLEAN; 

function  ••>="(A:  ADDRESS;  B:  ADDRESS)  return  BOOLEAN; 

function  "<=”(A:  ADDRESS;  B:  ADDRESS)  return  BOOLEAN; 

function  (A:  ADDRESS;  B:  ADDRESS)  return  INTEGER; 

function  (A:  ADDRESS;  I:  INTEGER)  return  ADDRESS; 

function  "-••  (A:  ADDRESS;  I:  INTEGER)  return  ADDRESS; 

function  (I:  UNSIGNED_TYPES.UNSIGNED_INTEGER)  return  ADDRESS; 
function  MEM0RY_ADDRESS  (I:  UNSIGNED_TYPES . UNSIGNED.INTEGER) 
return  ADDRESS  renames  "+"; 

N0_ADDR  :  constant  ADDRESS; 
type  TASK_ID  is  private; 

N0_TASK_ID  :  constant  TASK_ID; 
subtype  SIG_STATUS_T  is  INTEGER; 

SIG_STATUS_SIZE:  constant  :=  4; 
type  PROGRAM.ID  is  private; 

M0_PR0GRAM_ID  :  constant  PROGRAM_ID; 
type  LONG. ADDRESS  is  private; 

N0_L0NG_ADDR  :  constant  L0HG_ADDRESS ; 

function  (A:  LONG. ADDRESS ;  I:  INTEGER)  return  LONG.ADDRESS ; 
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function  (A:  LONG.ADDRESS ;  I;  INTEGER)  return  LONG. ADDRESS ; 
function  MAKE_LONG_ADDRESS  (A:  ADDRESS)  return  LONG. ADDRESS ; 
function  LOCALIZE(A:  LONG_ADDRESS  ;  BYTE.SIZE  :  INTEGER) 
return  ADDRESS; 

function  STATI0N_0F(A:  LONG.ADDRESS)  return  INTEGER; 

—  constant  for  use  in  attaching  tasks  to  interrupts 
SBC_NMI_INTERRUPT:  constant  ADDRESS; 

—  Constants  describing  the  configuration  of  the  CIFO  add-on  product. 
SUPPORTS_INVOCATION_BY_ADDRESS  :  constant  BOOLEAN  :=  TRUE; 
SUPPORTS_PREELABORATION  :  constant  BOOLEAN  :=  TRUE; 
MAKE_ACCESS_SUPPORTED  :  constant  BOOLEAN  :=  TRUE; 

—  Arguments  to  the  CIFO  pragma  INTERRUPT_TASK . 
type  INTERRUPT_TASK_KIND  is  (  SIMPLE,  SIGNALLING  ); 

—  Returned  by  ’task.id  for  passive  tasks, 
type  PASSIVE_TASK_ID  is  private  ; 

private 

type  ADDRESS  is  new  UNSIGNED_TYPES .UNSIGNED.INTEGER; 

NO_ADDR  :  const2ait  ADDRESS  :=  0; 

type  PASSIVE_TASK_ID  is  now  UNSIGNED_TYPES.UNSIGNED_INTEGER; 
SBC_NMI_INTERRUPT:  constant  ADDRESS  ;=  16#4000_0000#; 
pragma  BUILT_IN(">") ; 
pragma  BUILT_IN("<") : 
pragma  BUILT.IN (">=") ; 
pragma  BUILT. IN ("<=") ; 
pragma  BUILT.IN (••-") ; 
pragma  BUILT_IN("+") ; 

type  TASK.ID  is  new  UNSIGNED_TYPES.UNSIGNED_INTEGER; 

N0_TASK_ID  :  constant  TASK.ID  :=  0; 

type  PROGRAM.ID  is  new  UNSIGNED_TYPES.UNSIGNED_INTEGER; 

N0_PR0GRAM_ID  :  constant  PROGRAM.ID  :=  0; 

type  LONG.ADDRESS  is  new  UNSIGNED .TYPES. UNSIGNED.INTEGER; 

NO.LONG.ADDR  :  constant  LONG. ADDRESS  :=  0; 
pragma  BUILT.IN(MAKE_LONG.ADDRESS) ; 
pragma  BUILT.IN(LOCALIZE) ; 
pragma  BUILT.IN(STATI0N_0F) ; 
end  SYSTEM; 


F.2.2  package  CALENDAR 

package  CALENDAR 

The  following  is  the  specification  of  package  CALENDAR: 

package  CALENDAR  is 

type  TIME  is  private; 
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subtype  YEAR.IUMBER  is  IMTEGER  range  1901  ..  2099; 

subtype  MONTH.HUMBER  is  INTEGER  range  1  ..  12; 

subtype  DAY_NUMBER  is  IMTEGER  range  1  ..  31; 

subtype  DAY.DURATIOM  is  DORATIOH  range  0.0  ..  86_400.0; 

function  CLOCK  return  TINE; 

function  YEAR  (DATE  :  TIME)  return  YEAR_HUMBER; 

function  MONTH  (DATE  :  TIME)  return  M0NTH_NUMBER; 

function  DAY  (DATE  :  TIME)  return  DAY.NUMBER; 

function  SECONDS (DATE  :  TIME)  return  DAY.DURATION ; 

procedure  SPLIT  (DATE  :  in  TIME; 

YEAR  :  out  YEAR_NUMBER; 

MONTH  :  out  MONTH.NUMBER ; 

DAY  :  out  DAY.NUMBER; 

SECONDS  :  out  DAY_DURATION) ; 

function  TIME_0F(YEAR  :  YEAR.NUMBER; 

MONTH  :  MONTH.NUMBER; 

DAY  :  DAY.NUMBER; 

SECONDS  :  DAY.DURATION  :=  0.0)  return  TIME; 

function  "+■■  (LEFT  :  TIME;  RIGHT  :  DURATION)  return  TIME; 

function  "+••  (LEFT  :  DURATION;  RIGHT  :  TIME)  return  TIME; 

function  (LEFT  :  TIME;  RIGHT  :  DURATION)  return  TIME; 

function  (LEFT  :  TIME;  RIGHT  :  TIME)  return  DURATION; 

function  "<"  (LEFT,  RIGHT  :  TIME)  return  BOOLEAN; 

function  "<="  (LEFT,  RIGHT  :  TIME)  return  BOOLEAN; 

function  ">"  (LEFT,  RIGHT  :  TIME)  return  BOOLEAN; 

function  ">="  (LEFT,  RIGHT  :  TIME)  return  BOOLEAN; 

TIME.ERROR  :  exception;  —  can  be  raised  by  TIME.OF,  "+",  and 

private 

type  TIME  is  record 
MSH  :  Integer ; 

LSH  :  Integer; 
end  record; 

end; 
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F.2.3  package  MACHINE.CODE 

Package  MACHINE-CODE  provides  an  assembly  language  interface  for  the  target  machine 
including  the  necessary  record  types  needed  in  the  code  statement,  an  enumeration  type 
containing  all  the  opcode  mnemonics,  a  set  of  register  definitions,  and  a  set  of  addressing 
mode  functions.  Also  supplied  (for  use  only  in  units  that  WITH  MACHINE-CODE)  are 
PRAGMA  implicit-code  and  the  attribute  ’REF. 

Machine  code  statements  take  operands  of  type  OPERAND,  a  private  type  that  forms  the 
basis  of  aU  machine  code  address  formats  for  the  target. 

The  general  syntax  of  a  machine  code  statement  is 

CODE-n’(opcode,  operand  [,  operand])); 

where  n  indicates  the  number  of  operands  in  the  aggregate. 

When  there  is  a  variable  number  of  operands,  they  are  listed  within  a  subaggregate  using 
this  syntax: 

CODE-n’(opcode,  (operand  [,  operand]); 

For  those  opcodes  requiring  no  operands,  named  notation  must  be  used. 

CODE-O’(op  =>  opcode); 

The  opcode  must  be  an  enumeration  literal  (i.e.,  it  cannot  be  an  object,  attribute  or  a 
rename).  An  operand  can  only  be  an  entity  defined  in  MACHINE-CODE  or  the  ’REF 
attribute. 

The  ’REF  attribute  denotes  the  effective  address  of  the  first  of  the  storage  units  allocated 
to  the  object.  ’REF  is  not  supported  for  a  package,  task  unit  or  entry. 

Arguments  to  any  of  the  functions  defined  in  MACHINE-CODE  must  be  static  expressions, 
string  literals  or  the  functions  defined  in  MACHINE-CODE. 

F.2.4  package  SEQUENTIALJO 

Sequential  I/O  is  not  supported  by  the  RTE. 

F,2.5  package  UNSIGNED-TYPES 

package  UNSIGNED -TYPES  is  supplied  to  illustrate  the  definition  of  and  services  for  the 
unsigned  types  supplied  in  this  version  of  VADS.  Rational  Software  Corporation  does  not 
give  any  warranty,  expressed  or  implied,  for  the  effectiveness  or  legality  of  this  package.  It 
can  be  used  at  your  own  risk. 

Rational  Software  Corporation  intends  to  withdraw  this  implementation  if  and  when  the 
AJPO  and  the  Ada  community  reach  agreement  on  a  practical  unsigned  types  specification. 
We  can  then  standardize  on  that  accepted  version  at  a  practical  date  thereafter. 

The  package  is  supplied  in  comment  form  because  the  actual  package  cannot  be  expressed 
in  normal  Ada  -  the  types  are  not  symmetric  about  0  as  required  by  the  Ada  RM.  This 
package  is  supplied  and  is  accessible  through  the  Ada  WITHn  statement  as  though  it  were 
present  in  source  form. 

Example: 


517 


Defense  Systems  &: 
Electronics  Group 


Implementation-defined  A  ttributes 


MACS  Software  User’s  Manual 
4XT0010-00;  Version  1.0 
05  Etecember  1994 
APP:  Volume  1  of  5 


with  unsigned_types ; 

procedure  foo(  xxx:  unsigned_types.unsigned_integer)  is  ... 

CAUTION:  Use  package  UNSIGNED.TYPES  at  your  own  risk. 

A  complete  specification  of  package  UNSIGNED.TYPES  can  be  found  in  Appendix  F  of 
the  VADS  Programmer’s  Guide. 

F.3  Slices 

A  slice  denotes  a  one-dimensional  array  formed  by  a  sequence  of  consecutive  components 
of  a  one-dimensional  array.  A  slice  of  a  variable  is  a  variable;  a  slice  of  a  constant  is  a 
constant;  a  slice  of  a  value  is  a  value.  The  syntax  is: 

prefix(discretejrange) 

The  prefix  of  a  slice  must  be  appropriate  for  a  one- dimensional  array  type.  The  type  of  the 
slice  is  the  base  type  of  this  array  type.  The  bounds  of  the  discrete  range  define  those  of 
the  slice  and  must  be  of  the  type  of  the  index;  the  slice  is  a  null  slice  denoting  a  null  array 
if  the  discrete  range  is  a  null  range. 

For  the  evaluation  of  a  name  that  is  a  slice,  the  prefix  and  the  discrete  range  are  evaluated 
in  some  order  that  is  not  defined  by  the  language.  The  exception  CONSTRAINT  JERROR 
is  raised  by  the  evaluation  of  a  slice,  other  than  a  null  slice,  if  any  of  the  bounds  of  the 
discrete  range  does  not  belong  to  the  index  range  of  the  prefixing  array.  (The  bounds  of  a 
null  slice  need  not  belong  to  the  subtype  of  the  index.) 

F.4  Implementation-defined  Attributes 

’REF 

The  ’REF  attribute  denotes  the  effective  address  of  the  first  of  the  storage 
units  allocated  to  the  object.  ’REF  is  not  supported  for  a  package,  task 
unit  or  entry.  There  are  two  forms  of  use  for  this  attribute,  X’REF  and 
SYSTEM.ADDRESS’REF(N).  X’REF  is  used  only  in  machine  code  proce¬ 
dures  while  SYSTEM.ADDRESS’REF(N)  can  be  used  anywhere  to  convert 
an  integer  expression  to  an  address. 

X’REF 


The  attribute  generates  a  reference  to  the  entity  to  which  it  is  applied. 

In  X’REF,  X  must  be  either  a  constant,  variable,  procedure,  function  or  la¬ 
bel.  The  attribute  returns  a  value  of  the  type  MACHINE.CODE.OPERAND 
and  may  only  be  used  to  designate  an  operand  within  a  code-statement. 
The  instruction  generated  by  the  code-statement  in  which  the  attribute  oc¬ 
curs  may  be  preceded  by  additional  instructions  needed  to  facilitate  the 
reference  (i.e.,  loading  a  base  register).  If  the  declarative  section  of  the  pro¬ 
cedure  contains  PRAGMA  implicit-code  (off),  a  warning  will  be  generated 
if  additional  code  is  required. 
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SYSTEM.ADDRESS’REF(N) 


The  eflFect  of  this  attribute  is  similar  to  the  effect  of  an  unchecked  con¬ 
version  from  integer  to  address.  However,  SYSTEM.ADDRESS’REF(N) 
should  be  used  instead  in  the  following  listed  circumstances  and  in  these 
circumstances,  N  must  be  static. 

In  SYSTEM.ADDRESS’REF(N),  N  must  be  an  expression  of  type  UNI- 
VERSALJNTEGER  and  for  all  products  but  VADSself  on  VAX  VMS, 
SYSTEM.ADDRESS  must  be  the  type  SYSTEM.ADDRESS.  The  attribute 
returns  a  value  of  type  SYSTEM.ADDRESS,  which  represents  the  address 
designated  by  N. 

Within  any  of  the  run  time  configuration  packages: 

Use  of  unchecked  conversion  within  an  address  clause  would  require 
the  generation  of  elaboration  code  but  the  configuration  packages 
are  not  elaborated. 

In  any  instance  where  N  is  greater  than  INTEGER’LAST: 

Such  values  are  required  in  address  clauses  which  reference  the 
upper  portion  of  memory.  To  use  unchecked  conversion  in  these 
instances  would  require  that  the  expression  be  given  as  a  negative 
integer. 

To  place  an  object  at  an  address,  use  the  ’REF  attribute: 

The  integer^value  in  the  following  example  is  converted  to  an  ad¬ 
dress  for  use  in  the  address  representation  clause.  The  form  avoids 
UNCHECKEDXONVERSION  and  is  also  useful  for  32-bit  un¬ 
signed  addresses. 

— place  an  object  at  an  address 

for  object  use  at  ADDRESS ’REF  (integer.value) 


— to  use  unsigned  addresses 

for  VECTOR  use  at  SYSTEM. ADDRESS’REF(16#808000dO#) ; 
T0P\«0F\.MEM0RY  :  SYSTEM.ADDRESS  := 

SYSTEM . ADDRESS ’ REF ( 16#FFFFFFFF#) ; 


X’TASKJD 

For  a  task  object  or  a  value,  X,  X’TASKJD  yields  the  unique  task  ID 
associated  with  the  task.  The  value  of  this  attribute  is  of  the  type  SYS- 
TEM.TASKJD. 

F.5  Restrictions  On  ‘Main’  Programs 

VADS  requires  that  a  ‘main’  program  must  be  a  non-generic  subprogram  that  is  either  a 
procedure  or  a  function  returning  an  Ada  STANDARD  .INTEGER  (the  predefined  type). 
A  ‘main’  program  may  be  neither  a  generic  subprogram  nor  an  instantiation  of  a  generic 
subprogram. 
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F*6  Generic  Declarations 

VADS  does  not  require  that  a  generic  declaration  and  the  corresponding  body  be  part  of 
the  same  compilation  and  they  are  not  required  to  exist  in  the  same  VADS  library.  An 
error  is  generated  if  a  single  compilation  contains  two  versions  of  the  same  unit. 

F.6.1  Shared  Object-code  For  Generic  Subprograms 

The  VADS  compiler  generates  code  for  a  generic  instantiation  that  can  be  shared  by  other 
instantiations  of  the  same  generic  thus  reducing  the  size  of  the  generated  code  and  increasing 
compilation  speed.  There  is  an  overhead  associated  with  the  use  of  shared  code  instantiar 
tions  because  the  generic  actual  parameters  must  be  accessed  indirectly  and  in  the  case  of  a 
generic  package  instantiation,  declarations  in  the  package  are  also  accessed  indirectly.  Also, 
greater  optimization  is  possible  for  unshared  instantiations  because  exact  actual  parameters 
are  known.  It  is  the  responsibility  of  the  programmer  to  decide  whether  space  or  time  is 
most  critical  in  a  specific  application. 

To  give  the  programmer  control  of  when  an  instantiation  generates  unique  code  or  shares 
code  with  other  similar  instantiations,  PRAGMA  share.code  is  provided.  This  PRAGMA 
can  be  applied  to  a  generic  declaration  or  to  individual  instantiations. 

It  is  not  practical  to  share  the  code  for  instantiations  of  all  generics.  If  the  generic  has  a 
formal  private  type  parameter  the  generated  code  to  accommodate  an  instantiation  with 
an  arbitrary  actual  type  would  be  extremely  inefficient. 

The  VADS  compiler  does  not  share  code  by  default.  The  INFO  directive  SHARE.-BODY 
may  be  specified  in  a  VADS  library  to  cause  the  compiler  to  always  share  generic  code 
bodies.  PRAGMA  share_code  may  be  applied  to  generic  units  or  generic  instances  to 
control  whether  specific  instances  are  shared. 

To  override  the  default,  the  PRAGMA  share_code(name,  false)  must  be  used.  If  there  are 
formal  subprogram  parameters  instantiations  will  not  be  shared  unless  an  explicit  PRAGMA 
share_code(name,  true)  is  used. 

The  PRAGMA  share_code  is  used  to  indicate  desire  to  share  or  not  share  an  instantiation. 
The  PRAGMA  can  reference  either  the  generic  unit  or  the  instantiated  unit.  When  it 
references  a  generic  unit,  it  sets  sharing  on  or  off  for  all  instantiations  of  that  generic 
unless  overridden  by  specific  share^code  PRAGMAS  for  individual  instantiations.  When  it 
references  an  instantiated  unit,  sharing  is  on  or  off  only  for  that  unit. 

The  PRAGMA  sharexode  is  only  allowed  in  the  following  places:  immediately  within  a 
declarative  part,  immediately  within  a  package  specification  or  after  a  library  unit  in  a 
compilation  but  before  any  subsequent  compilation  unit.  The  form  of  this  PRAGMA  is 

PRAGMA  share.code  (generic,  boolean.literal) 

Note  that  a  parent  instantiation  (the  instantiation  that  creates  the  sharable  body)  is  inde¬ 
pendent  of  any  individual  instantiation,  therefore  reinstantiation  of  a  generic  with  different 
parameters  has  no  effect  on  other  compilations  that  reference  it.  The  unit  that  caused  com¬ 
pilation  of  a  parent  instantiation  need  not  be  referenced  in  any  way  by  subsequent  units 
that  share  the  parent  instantiation. 

Sharing  generics  causes  a  slight  execution  time  penalty  because  all  type  attributes  must  be 
indirectly  referenced  (as  if  an  extra  calling  argument  were  added).  However,  it  substantially 
reduces  compilation  time  in  most  circumstances  and  reduces  program  size. 
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We  have  compiled  a  unit,  SHAREDJO,  in  the  standard  library  that  instantiates  all  Ada 
generic  I/O  packages  for  the  most  commonly  used  base  types.  Thus,  any  instantiation  of 
an  Ada  1/ 0  generic  package  will  share  one  of  the  parent  instantiation  generic  bodies  unless 
the  following  PRAGMA  is  used: 

PRAGMA  share_code  (  generic ,  false  ) ; 


F.7  Representation  Clauses 

F.7.1  Bit-level  Representation  Clauses 
VADS  supports  bit-level  representation  clauses. 

F.7.2  PRAGMA  pack 

VADS  does  not  define  any  additional  representation  PRAGMAS. 

F.7. 3  Length  Clauses 

VADS  supports  all  representation  clauses. 

F.7.4  Enumeration  Representation  Clauses 
Enumeration  representation  clauses  are  supported. 


F.7.5  Record  Representation  Clauses 

Representation  clauses  are  based  on  the  target  machine’s  word,  byte  and  bit  order  num¬ 
bering  so  that  VADS  is  consistent  with  machine  architecture  manuals  for  both  ‘big-endian’ 
and  ‘little-endian’  machines.  Bits  within  a  STORAGE_UNIT  are  also  numbered  according 
to  the  target  machine  manuals.  It  is  not  necessary  for  a  user  to  understand  the  default 
layout  for  records  and  other  aggregates  since  fine  control  over  the  layout  is  obtained  by  the 
use  of  record  representation  clauses.  It  is  then  possible  to  align  record  fields  correctly  with 
structures  and  other  aggregates  from  other  languages  by  specifying  the  location  of  each 
element  explicitly.  The  ’FIRST-BIT  and  ’LAST-BIT  attributes  can  be  used  to  construct 
bit  manipulation  code  that  is  applicable  to  differently  bit-numbered  systems. 

A  figure  (or  figures)  illustrating  the  addressing  and  bit  numbering  scheme  available  for  your 
target  system  can  be  found  in  Appendix  F  of  the  Programmer’s  Guide. 

The  only  restriction  on  record  representation  clauses  is  that  if  a  component  does  not  start 
and  end  on  a  storage  unit  boundary,  it  must  be  possible  to  get  it  into  a  register  with  one 
move  instruction. 


F.8  Change  of  Representation 

Change  of  representation  is  supported. 
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F.9  package  SYSTEM 

The  specification  of  package  SYSTEM  is  available  in  the  Appendix  F  chapter  of  the  Pro¬ 
grammer’s  Guide.  The  PRAGMAS  system_name,  storage_unit  and  memory jsize  are  recog¬ 
nized  by  the  implementation  but  have  no  effect.  The  implementation  does  not  allow  SYS¬ 
TEM  to  be  modified  by  means  of  PRAGMAS,  however,  the  same  effect  can  be  achieved  by 
recompiling  the  SYSTEM  package  with  altered  values.  Note  that  such  a  compilation  will 
cause  other  units  in  the  STANDARD  library  to  become  out  of  date.  Consequently,  such 
recompilations  should  be  made  in  a  library  other  than  standard. 

F.9.1  System-Dependent  Named  Numbers 

The  specification  of  package  SYSTEM  is  listed  on  page  F.2.1.  This  specification  is  also 
available  on  line  in  the  file  system.a  in  the  release  standard  library. 


F.IO  Representation  Attributes 

F.lO.l  ’ADDRESS  attribute 

The  ’ADDRESS  attribute  is  supported  for  the  following  entities. 

•  variables 

•  constants 

•  procedures 

•  functions 

If  the  prefix  of  an  address  attribute  is  an  object  that  is  not  aligned  on  a  storage  unit 
boundary,  the  attribute  yields  the  address  of  the  storage  unit  containing  the  first  bit  of  the 
object.  This  is  consistent  with  the  definition  of  the  FIRST_BIT  attribute. 

All  other  Ada  representation  attributes  are  fully  supported. 

F.10.2  Representation  Attributes  of  Real  Types 
These  attributes  are  supported. 


F.ll  Machine  Code  Insertions 

Machine  code  insertions  are  supported. 


F.12  Interface  to  Other  Languages 

The  VADS  interface  to  other  languages  is  discussed  in  the  Interface  Programming  chapter 
in  the  VADS  Reference  Guide  and  in  the  section  PRAGMAS  and  Their  Effects. 
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F.13  Unchecked  Programming 

Both  UNCHECKED_DEALLOCATION  and  UNCHECKED.CONVERSION  are  provided. 

F.13.1  Unchecked  Storage  Deallocations 

Any  object  that  was  allocated  may  be  deallocated.  When  an  object  is  deallocated,  its  access 
variable  is  set  to  null.  Subsequent  deallocations  using  the  null  access  variable  are  ignored. 

F.13.2  Unchecked  Type  Conversions 

The  predefined  generic  function  UNCHECKED -CONVERSION  cannot  be  instantiated  with 
a  target  type  that  is  an  unconstrained  array  type  or  an  unconstrained  record  type  with 
discriminants. 

F.14  Parameter  Passing 

Parameters  are  passed  in  registers  and/or  by  pushing  values  (or  addresses)  on  the  stack. 
Extra  information  is  passed  for  records  (’CONSTRAINED)  and  for  arrays  (dope  vector 
address). 

Small  results  are  returned  in  registers;  large  results  with  known  targets  are  passed  by 
reference.  Large  results  of  anonymous  target  and  known  size  are  passed  by  reference  to  a 
temporary  created  on  the  caller’s  stack.  Large  results  of  anonymous  target  and  unknown 
size  are  returned  by  copying  the  value  down  from  a  temporary  in  the  callee  so  that  the 
space  used  by  the  temporary  can  be  reclaimed. 

The  compiler  assumes  the  following  calling  conventions. 

1.  Caller  passes  scalar  arguments  in  aO,  al,  a2  and  a3  and  floating  pointer  arguments 
in  fl2  and  fl4.  Other  arguments  are  passed  on  the  stack.  Inter-language  calls  (for 
example,  from  a  C  routine  to  an  Ada  routine  or  from  an  Ada  routine  to  a  C  routine)  use 
the  standard  MIPS  calling  convention.  To  call  a  C  procedure,  declare  the  Ada  interface 
using  PRAGMA  interface  (language,  subprogram).  To  declare  an  Ada  procedure  that 
will  be  called  from  C  or  FORTRAN,  use  PRAGMA  external  (language,  subprogram). 

2.  Caller  calls  callee. 

3.  Callee  allocates  space  for  locals,  if  needed,  by  subtracting  from  the  stack  pointer.  If 
the  stack  pointer  is  changed,  then  a  stack  overflow  check  is  executed. 

4.  Callee  preserves  registers  in  the  set  s0-s7,  sp,  s8  and  ra  if  they  are  used.  Also,  registers 
f20  through  f30  are  saved  if  used. 

5.  Callee  copies  the  display,  if  needed. 

6.  Callee  sets  up  a  frame  pointer  (r30,  aka  fp)  if  the  sp  is  modified  by  code  during  the 
call.  Otherwise,  a  virtual  frame  pointer  is  used. 

7.  Callee  executes. 
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8.  Callee  puts  return  result  in  vO  or  fO. 

9.  Saved  registers  are  restored. 

10.  The  stack  pointer  is  restored,  which  reclaims  local  storage. 

11.  The  callee  returns  to  the  caller. 

Note  that  machine  code  insertions  can  be  used  to  explicitly  build  a  call  interface  when 
compiler  conventions  are  not  compatible  or  when  interfacing  to  assembly  language. 

It  is  important  to  understand  the  referencing  of  parameters  when  using  machine-Code  in¬ 
sertions.  Parameters  cannot  be  treated  like  memory  locations  since  in  may  cases,  they  are 
being  held  in  registers.  Attempting  to  treat  a  parameter  held  in  a  register  like  a  memory 
location  will  cause  a  compiler  error. 

F.15  Conversion  And  Deallocation 

The  predefined  generic  function  UNCHECKEDXONVERSION  cannot  be  instantiated  with 
a  target  type  that  is  an  unconstrained  array  type  or  an  unconstrained  record  type  with 
discriminants. 

There  are  no  restrictions  on  the  types  with  which  generic  function  UNCHECKED-DE¬ 
ALLOCATION  can  be  instantiated.  No  checks  are  performed  on  released  objects. 


F.16  Types,  Ranges  and  Attributes 

The  maximum  ARRAY,  RECORD  and  TYPE  size  limits  have  been  increased  to  256_000_000. 


F.17  Numeric  Literals 

VADS  Ada  uses  unlimited  precision  arithmetic  for  computations  with  numeric  literals. 


F.18  Enumeration  Types 

VADS  Ada  allows  an  unlimited  number  of  literals  within  an  enumeration  type. 


F.19  Attributes  of  Discrete  Types 

VADS  Ada  defines  the  image  of  a  character  that  is  not  a  graphic  character  as  the  cor¬ 
responding  2-  or  3-chaxacter  identifier  from  package  ASCII  of  Ada  RM  Annex  C-4.  The 
identifier  is  in  upper  case  without  enclosing  apostrophes.  For  example,  the  image  for  a 
carriage  return  is  the  2-character  sequence  CR  (ASCII.CR). 
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F.20  The  type  STRING 

Except  for  memory  size,  VADS  Ada  places  no  specific  limit  on  the  length  of  the  predefined 
type  STRING.  Any  type  derived  from  the  type  STRING  is  similarly  unlimited. 


F.21  The  type  INTEGER 


The  following  are  the  INTEGER  attribute  values: 


type  INTEGER  Attribute  Values 

Name  of 

Attribute  Value 

Attribute  Value  of 

Attribute  Value  of 

Attribute 

of  INTEGER 

SHORTJNTEGER 

TINYJNTEGER 

SIZE 

32 

16 

8 

FIRST 

-2_147_483_648 

-32_768 

-128 

LAST 

2_147.483_647 

32.767 

127 

F.22  Operation  of  Floating  Point  Types 


VADS  Ada  floating  point  types  have  the  attributes  given  in  the  following  table; 


Floating  Point  Types 

Name  of 

Attribute 

Attribute  Value  of 
LONGJFLOAT 

Attribute  Value  of 
FLOAT 

SHORT  J'LOAT 

SIZE 

64 

32 

FIRST 

-1.79769313486232E-f-308 

-3.40282E-I-38 

LAST 

1.79769313486232E-I-308 

3.40282E-1-38 

DIGITS 

15 

6 

MANTISSA 

51 

21 

EPSILON 

8.88178419700125E-16 

9.53674316406250E-07 

EMAX 

204 

84 

SMALL 

1.94469227433161E-62 

2.58493941422821E-26 

LARGE 

2.57110087081438E-b61 

1.93428038904620E-1-25 

SAFEJiMAX 

1021 

125 

SAFE.SMALL 

2.22507385850720E-308 

1.17549435082229E-38 

SAFEJ.ARGE 

2.24711641857789E+307 

4.25352755827077E-I-37 

MACHINEJIADIX 

2 

2 

MACHINEAIANTISSA 

53 

24 

machinej:max 

1024 

128 

machinej:min 

-1021 

-125 

MACHINEJIOUNDS 

TRUE 

TRUE 

MACHINE-OVERFLOWS 

TRUE 

TRUE 
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